Conversation
|
Jonas Elfering (@keulinho) ready to review already, or should we wait till it's out of draft? |
|
|
||
| Upgrade plans should protect customer data and keep extensions compatible. Rehearse upgrades on staging with production-like data before touching production, and keep recovery steps ready. | ||
|
|
||
| ## Cross-cutting practices |
There was a problem hiding this comment.
It's also worth mentioning both keeping up with updates (ie. update once a quarter) and also to make use of the backwards compatability that is added to new features - these allow a cross-over period when new feature is available but behind a feature flag -> these times should be used to do the upgrade without it being on the critical path.
|
Heads up: With approval from Jonas Elfering (@keulinho) I'll fold this content into other docs changes I'm making, as this info will serve as valuable "anchoring" context in our upcoming, new "Development" docs section. |
| ## Cross-cutting practices | ||
|
|
||
| - Roll forward by default; keep rollbacks minimal (DB-aware and version-pinned) and practice them. | ||
| - Use maintenance mode for schema-changing releases; add health checks and smoke tests post-deploy before exiting maintenance. |
There was a problem hiding this comment.
mention those system:check thingy?
Will it be part of #2111 ? |
5 participants
First draft to collect good practices for external devs to follow
mostly intended to give guidance and link out to the correct existing section in the docs